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DATA REPLICATION SYSTEM AND are not practical for a number of reasons. For example, a 

METHOD lock must be visible to every transaction that accesses a copy 

of the database. This is not possible for copies of the 

BACKGROUND OF THE INVENTION database on cUent computers that are disconnected from the 

,„.,,,.,,,. s network. In a connected environment, the cast of acquiring 

1. Field of the Invention a lode that is visible to all copies of the database is 
The present invention relates to design of distributed data prohibitive because making a lock usable across a network 

systems and methods, and more particularly, to design of requires passing of messages. 

data replication systems and methods. Another problem with using locks to serialize transactions 

2. Description of the Related Art lo agiunst different copies of a database is that if a lock is 
Distributed data systems (and methods) use a central ''.^"''f ^"f^^ble network, very difficult faUure 

database with copies of that daUbase distributed to client situalofs s^^ch as network partitions. Moreover, if the 
computers within the system. For example, in a conventional ^^"^V '^f''*** ^1°° ^ "^er in agreement with the copies of 
distributed data system having a central server computer and «ie database at ^e chent databases, there is an increased 
one or more client computers, each client computer uses a 15 Probabdity that the daU m the distnbuted data system may 
copy of the central database or data repository Uiat is located ^^""""^ compromised. Once tiie data is compromised, the 
on the server computer. Each client computer performs ^Jl*'^™ '^'^ conventional data replication systems 
computer application functions and operations using the *P°^°g both "read'; and "write" transactions are not suit- 
copy of tile database, lb keep each copy of the database at . niission cntical distributed data systems where 
the client computer matching v^th the central database M mamtammg data mtegrity is essential, 
located at the server computer, conventional distributed data . conventional replication data processing systems it 
systems use conventional data replication systems difficult to build an automatic mechanism to guarantee 
Cbnventional data replication systems provide high data T'^'^T update different copies of 
availability and enhance performance by allowing a copy of ^^JZ^^' 1 f 't . 'il:"")^'"' '^f ° f*' 
the database to be moved from the seiner computer to the ^ f^^em which contribute to ttie difficulty inchide requiring 

cUent computers thereby eliminating or removing system ^'r'^''^?,'™ ^, '^''^^l "'"^'•^'ff ^ 

botflenecks such as numerous input/output operations with f JT^^se rules may be complex. Often no declarative 

the server computer. Conventional data replication systems, ^^ "^^^ exists. In fact for many apphcations the 

however, have a number of drawbacks. only pracUcal way to specify the consistency rules for a 

u- . , . 30 database is to wnte complex procedural loric, snedficallv 

First, many conventional rephcauon systems only allow triggers. ^pci-iutaiiy, 

for computer applications to "read" the copy of the database a f„„-i, „,„ki» i ^ . 

at Ac client computer. To ensure consistenS' and agreement , ^'T "^ convenUonal data rephcatton sys- 

these conventional replication systems do not perform both u^.t^^'^T'^ I'T "^T' ft'-'^''] 
a "read" and a "write" with tiie copy of the seiner database ! ' „ ! ' / a^arbitrary number of addiUonal 
Specifically, these conventional refucation system are fZ^T.^l f "^'"r °" '''t'^'l r 
cemed with the data integrity of the server database becTiS- lT!!f ft"""" ConvenUonal replication systems do 
ingcompromisedif.forexaiple,acopyofUiedatabaseon ll^^LTlhtl'T TVT"^^^^^ 
Uieclientcomputerisupdatedbutthecentraldatabaseonthe f_,™7^'*at changes made by ftese dependent trans- 
server computer is noi properly updated. Read only dZ '^f'^^.^'*"'- '^'^ ^"^^ 
replication systems, therefor^ a^e not well suited for'com ^ "'■^*^'^°^y 
puter applications that perform transactional functions and a fif.u ui -.u . . 
operations at Uie client computer problem with conventional data replication sys- 

Other conventional replication systems allow both 

"reads" and "writes" to the ^py of the Server database at toe f,^. ? tramaction. For example, if a server data- 

cUent computer. Hese conventional repuLt^n system^ teTJ m.vt int?;^ ^"^'"""^^"".^^^^^^ 

however, cannot guarantee agreemenfand consLency' 5^ "ed secfenTf Se lo/Z'™ H 1 T 'T."'' 

between the server database itself and the copy of tiie server Jl f ? T ,u ^' ^ ^ ' ^^^^"^^ 

I 1 , ■■ . server gj^ch transactions. In the case that the target database holds 

dat^^ase. In parUcular convenUona] replicaUon systems are , transaction that the server database tertn^entional 

unable to correctly serialize transactions that are apphed to ^pUeation systems become confused. '=°°^'=°tional 

the various copies of Uie server database. Moreover, trans- » ■ ,i, ui -.i. ■ , . 

actions cannot be serialized in such systems witiiout f ^ ^'u"""^ with conventional data replication sys- 

adve^ely affecting overall system performance '^'^ ^^"^ ^° °°' LyPically automate the distribution 

T. • . J .1. . J . 1. • . , , aspects of a computer software upgrade such that the client 

sll^V y \t A « "T^"^ "consistent" if it computer remains operable and the^database u^abk Many 

atisfies all applicable user defined consistency rules so that 55 existing data replication systems require new softw^ or 

Sen74feJ . r .r'^ T^Tu "Pg^*^' "'""y instaUatio J on every^lient c^niutrr Dur' 

mfnnr ^trl^ Tl T'"" ' ^^"^l"^ agree despite i„g the installation process, the cUenl computer nL reml 

^r^SfnT/H . '""^'"".rf """^"'^ ^ 'bat Uie database is not Lrrupted. T^^ 

T^e copies of a database in a correctly functionmg rephca- successful, the instaUation must be well plann^, including 
Uon system must hem agreement, although they may never ,0 recovery plans in flit event Uiat Uie upgrade ^Thf 

S^b'oS<2„H""°H « instaUationmustalsobewelltestedand^nattiSSwEn 

tZ^^l. 1^ H r .T''^^™' ^""'^ * P'"*""*' client computers are least used so Uiat the process is least 

tiiat ensures that each chent database is m agreement with disruptive. Thus, existing data replication Sms 

both the server database and Uie oti,er chent databases. „tiwieldy, especiaUy in large instaUations, for eSpTe ha"! 

A thud problem with conventional data replication sys- 65 ing 10,000 chent computers and are not well suited in 
teiLS arises froin Uie use of locks to prevent conflicts increments requiring a high degree of cUent computer avail- 
between ti^ansacUons that access different copies. Such locks ability. 
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Therefore, there is a need for a data replication system and recover message, that includes a new generation name for 

method that (1) allows for replicating or copying a source the source database, to the target database system. The target 

database across multiple client computers and (2) allows database system receives the recover message and stores the 

each client computer to freely transact, i.e., both "read" and new generation name for the source database, 

"write," with the copy of the database while (3) providing 5 The target database system returns the target database to 

database consistency to ensure data mtegnty and (4) allow- a stable pure state. The stable pure state is a most recent state 

mg for complete disaster recovery. the target database that has only transactions not lost by 

SUMMARY OF THE INVENTION source database. Once at the stable pure state, the target 

database system extends the list of provisional transactions 

The present invention includes a data replication process- lo to include all local transactions stored by the target database 

ing system and method. The replication processing system system since the last stable pure state. The target database 

comprises a source database system that includes a source system then performs a re&esh operation to redo the provi- 

database and a target database system that includes a target sional transactions at the target database and the source 

database. The source database system and the target data- database. 

base system arc coupled through a network. Hie target 15 ji,^ replication processing system also includes a method 

database holds a subset of the source database. upgrading an application in the Uiget daubase system. 

•nie data repUcation processing system allows for a Specifically, the repUcation processing system appends an 
method to update both the source database and the target application identifier and a first application version for the 
database so that at a given instant the data set at the source application to a refresh request message. The source data- 
database IS m agreement with the data set of the target ^ base system receives the application information in the 
database. The method generates a refresh request message at refresh request message and builds an upgrade reply mes- 
the target database systemfor defivery to the source database sage in response to the first application version being older 
system. The refresh request message includes a list of than a second application version of the application at the 
provisional transactions applied to the target database since source database system. 

a last refresh operation was performed by the replication ^ -n,. , j . u < . . , 

processing system. TTie source database system transmits the upgrade reply 

n i u . ■ . , . . message to the target daubase system. The upgrade reply 

Tht refresh request message is received by the source „jessage includes an upgrade block that has thelppUcation 

database system, which i^phes the provisional transactions identification, the first application version, the second appU- 

to Its source database. TTie source database system con- cation version, and data bytes for upgrading the application, 

shucts a refresh reply message for delivery to the target The target database system peifor^ an upgrade of the 

database systern. The refresh reply message mchides a list of application at the target database system using the upgrade 

transactions it has apphed to the source database smce the block received in the upgrade reply message 

last refresh operation. These transactions include the provi- „• .j.i.... .7 - . 

sional transactions from target database. " "^^^ ^ ^ ''^'^ rephcaUon system m one embodi- 

xu„ u _ 1 • • J L ■ 35 mcludes at least one processor for processine source 

d.t^!jt """"""""^ transactions and provisional transactions for the so^c 

^VTrett"^^^^ apphes the source transacUons instructions. The instructions L executed by the processor 

from the refresh reply message to the target database. The to cause the processor to update the data set by causing the 

source database and the target database now match This «r«/^.ce^, ** i * 7 j ^ ^-^u^uig 

r,o„, «f ♦u J * u J " ui'ii^ii- ima> processor to perform particular steps for a data replication 

new state of the source database and the target database is process ^ *' ^ icjjuL^auuu 

saved as a source commit instant, and may be referenced for ™ j 

future refresh operations features and advantages described in the specification 

If the target database system received additional provi- ^J^'f'""^" "^^ll P""^^^"' "^'^^ "^^'^^'^^ 
sional transactions after generating and sending its refresh 1?^!^^ ^ be apparent to one of ordinary 
request message, those trLactions are saved in^a storage of '^f J ^If " ^^^TJf I Tf^^''^^^' 
the target database system. These transactions are referred to ' Te .^"'w ^ '^''u ""^"^ "^"^ ^"^fc^^ ^"'^ 
as stranded transactions and are appHed to the target data- Imv Tnd S^ ^'""^'^'^^^ selected for read- 
base after the transactions from the refresh replylaessage tS^^^n ^ ^^^^'^'^ u''"" 
are applied selected to dehneate or curcumscnbe the mventive subject 

r«_ . . matter. 

The replication processing system of the present invention 

also includes a method for restoring agreement between the BRIEF DESCRIPTION OF THE DRAWINGS 

source database and the target database in the event of a 55 

database failure, e.g., a source daUbase crash, automatically ^^OS. la and lb are block diagrams illustrating one 

(i.e., without user intervention). The method provides a <^mbodiment of a data processing system in accordance with 

generation name of the source database to the target database present invention; 

system that is stored in storage by the target database system. P^G. 2 is a block diagram illustrating one embodiment of 

The target database system includes the generation name in go ^ replication processing system in accordance with the 

a refresh request message to the source database system. The present invention; 

generation name changes when the source database system FIG. 3 is a flow diagram illustrating one embodiment of 

recovers from a database failure. a refresh operation in a replication processing system in 

The source database system verifies that the generation accordance with the present invention; 
name received from the target database system matches the 65 FIG. 4 is a flow diagram iUustrating one embodiment for 
generation name of the source database. If the generation constructing a refresh reply message in a replication pro- 
names do not match, the source database system sends a cessing system in accordance with the present invention; 
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FIG. 5 is a flow diagram illustrating one embodiment of noted that the general server computer 125 may be optional, 

application of the refresh reply message in a replication The database server computer 120 may also be referred to as 

processing system in accordance with the present invention; the database source computer 120 and the client computer 

FIG. 6a is a flow diagram iUiistrating one embodiment of 130 may also be referred to as target computers 130. 

a refresh operation for transaction applied to the target 5 [n the data processing system 105a the server computers 

database, but not the source database, in a replication 120, 125 and the client computers 130 are all coupled to the 

processing system in accordance with the present invention; computer network 110. The computer network 110 facili- 

FIG. 6b is a flow diagram iUustrating a process for tates commimications between the computers 120, 125, 130. 

updating a target database system upon receiving a refresh The computer network 110 is capable of delivering bytes 
reply message from a source database system in a replication ^° of data, e.g., messages, from one computer, e.g., the server 

processing system in accordance with the present invention; computer 120, to another computer, e.g., the database target 

FIG. 6c is a timing diagram illustrating one example for computer 130. The computer network 110 may be a local 

application of transactions applied to both a source database network ("LAN"), wide area network ("WAN") (e.g., 

and a target database; the Internet), a telecommtmications network, a computer 

FIG. 7 is a flow diagram illustrating one embodiment of co^iponent network (e.g., a file transfer system), a message- 

operation of a messaging module in a replication processing ^^^^ network, or other functionally equivalent data transfer 

system in accordance with the present invention- network system. Further, the computer network 110 may be 

HG. 8 is a state diagram illustrating one example of a 1^7?^^ .^^ "J^^ ^^^^ are coupled together 
transaction nature of "source databL in a repUcation 20 ^^''^^f^^^^^^^^^^^^^^ 

processing system in accordance with the present Son; ^^^^P"'^" P^"^^'^^ ^''^'^ ^^^^ ^^^^^^^0- 

HG. 9 is a flow diagram illustrating processing of .J^LTZ^'^^'''^'" T^-^' 1^ "^"^^T 

strandedtransact:onsinconjuncUonw.thaf^^^^^^ I^Sm^^T^^^^ 

p^senTi^^^^^^^^ " "^"'"^^ ^s Microsystems or other RISC bas!d co^^^ 

iTTr- in - « ' J- - an Apple Computer server, an Intel-processor based server 

FIG. 10 IS a flow diagram lUustratmg a detection process computer; or other functionally equivalent computer The 

for a failure m a replication processing system in accordance server also runs appropriate operating system software for 

with the present mvention; example, IBM VM or AIX, Sun OS or Solaris, Apple System 

FIG. 11 is a flow diagram illustrating a correction process 8 (or later), or Microsoft Windows NT or Windows 95 (or 

for a failure in a replication processing system in accordance later) . 

with the present invention; The client computer 130 may be any computer capable of 

FIG. 12 is a flow diagram illustrating a marker transaction handling client computer functions, for example, another 

in the replication processing system in accordance with the server computer operating in a client mode, a Sun Micro- 
present invention; 3^ systems or other RISC-based workstation, an Intel-processor 

FIG. 13 is a flow diagram iUustrating a submit transaction ^^^^ workstation, a personal digital assistant, a processor 

operation in the replication processing system in accordance based controUer, or other functionaUy equivalent computer, 

with the present invention; Each client also runs appropriate operating system software, 

HGS. 14a and Ub are flow diagrams illustrating a I?' example, IBM AIX, Sun OS or Solaris, or Microsoft 
checksum process for a replication processing system in 40 Wmdows NT or Window 95 (or later), 

accordance with the present invention; 1^ illustrates an embodiment of a logical configu- 

FIG. 15 is a flow diagram illustrating an upgrade process ^^^^f ^^^^ processing system illustrated in FIG. 

andutiUty for a replication processing system in accordance ? accordance with the present invention. In the logical 

with the present invention* configuration lOSb, a hub-and-spoke topology includes a 

no. 16 is a flow dia'gra. illustrating a process for « s^J^^ rSr^^^Ts^anTJ:^^^^ 

rnn tn- a Fi<=»cm luvcnuon, ana supports transactions. For example, the server system and 

FIG. 17 IS a flow diagram illustraUng a process for the target system may be a database system, a file transac- 
applying an upgrade reply message ma replication process- 50 tional system, or the like. In one embodiment, the source 

mg system m accordance with the present invention. system is a source database system 140 and the target system 

DETAILED DESCRIPTION OF THE ^ database system 150. 

PREFERRED EMBODIMENTS ^^^Set database system 150 is coupled to the source 

.... J. , , database system 140. The source database system 140 is the 

A preferred embodiment of the present invention will be 55 "hub" database and each target database system 150 is a 

described with reference to the Figures, where like reference "spoke" database. It is noted that the source database system 

numbers t>jpicany mdicate identical or functionally similar 140 may be comprised of one or more databases that are 

elements Tie present mvenUon mcludes a system and a coupled together as a single logical source database. Simi- 

method for data replication m a distributed environment. larly any or aU of the target database systems 150 may be 

System Overview '° comprised of one or more databases that are coupled 

1J1/-C 1 A 11. ^ together as a single logical target database. Each target 

HUi.. la and lb are blodc diagrams illustrating one database system 150 is autonomous and is a cached subset 

embodiment of a data processing system in accordance with (e.g., a subset copy) of the source database system 140 

tiie present mvention. Fia la illustrates a physical layout of In one embodiment of the present invention, the source 

data processing system 105a that includes a computer net- 6S database system 140 is resident on the database server 

work 110, a database seiver computer 120, a general server computer 120 while each target database system 150 is 

computer 125, and one or more client computers 130. It is resident on a client computer 130. It is noted, however that 
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both the source database system 140 and the target database (Jul. 23, 1992) (from the Open Software Foundation 

system 150 may be resident on either the server computer standards) and is hereby incorporated by reference. 

120 or the client computer 130. Farther, in the logical For simplicity, operation of the repHcation processing 

hub-and-spoke configuration 1056, an application may be system 205 will be described from a target database system 

deployed with the one or more target database systems 150 s 150 perspective. One skiUed in the art will appreciate that 

on the client computer 130. Because only a subset of the the general principles of operation also apply to other target 

source database system 140 that is relevant to the application database systems 150 as well as the source database system 

at the client computer 130 is provided for the target database 140 perspective 

system 150 processing and storage resources on the client m database module 248, 258 provides conventional data 
computer lJU are saved. lO management services. In addition, the database module 248, 
Also, m a preferred embodiment of the present invention 258 also collects changes to the published data and makes 
the source database system 140 and the target database these changes available to the replication module 246, 256. 
system 150 are enabled and implemented m a Sun Micro- Organization and use of the changes by the database module 
systems' Java™ software environment. Further, in a pre- 248, 258 and the replication module 246, 256 is further 
ferred embodiment the source database system 140 and the 15 described below. The database module 248 258 also pro- 
target database system execute in a single Java Virtual vides database recovery services, as is also fiirther described 
Machme ("JVM"). Moreover, the smgle JVM may be below. 

executing on one computer or ainong multiple compute^. The replication module 246, 256 implements a repHcation 

The present invention may also be configured so that the * i • ^ vi_ *t. ^ uvi^a i^ii^<tuyu 

souri database system 140 runs in one JVM and the taiget ^ • "7°"°°- 1°,™?]'/ 

database system 150 runs in a second JVM. It is noted L ' Protocol, the repLcation module 246 

.v-ii-i fu . n • /' ""'y^ '"'" 256 provides services such as, for example, dcfinine a set of 

one skilled m the art will recognize that present mvenlion „„ki;oI,<.j r • . . j . u ""^s "i 

may be enabled and implemented in other funcUonally C^trT,'^ "^^ I a target database system 150 to 

similar software environments. ^"H" """T . i °^ """""^ 

. ^- r ,L J . n< "a'aoase system 140, and performmg a refresh operation on 

.in^TLS'T °f data proc6s..ang system 105 ^ a target database system 150. Tie refresh operation makes 

(lOSa, 1056), the target database system 150 caches a subset the cached data at the target database system 150 more 

of (ie data from the source database system 140. Havmg a current by applying changes made by the target database 

cached subset of Uie data allows the chent computer 130 system 150 to the source database system 140 as well as 

(and Its target database system 150) to operate disconnected applying changes made by the source database system 140 

™,trlTrH% hT,,'' to the target database system 150. The refresh operation is 

computer 120 (and its source database system 140). further described below 

The source database system 140 publishes data available The messaging module 244, 254 deUvers messages, or 

or caching In one embochmen^ Uie data includes, for streams of bytes, fn^m the re;pective replication module 

exmiple. database software SQL dictionary objects such as 246, 256 in one database system 140, 150 to the respecUve 

iShllToT hr""' T'h '^P'i^'^"" -""dule 246. 256 in the ;ther database system 

f.wr^nf.H^h^Mr' "^f ^"V.H^rM ' f r ' l*"- '^^ ^Pi^^^^^on module 246, 256 uses the mes- 

(s). It IS noted that the contents of the tables may include, for saging module 244. 254 to transmit information between the 

caZ ^;t!TH r f°^.'"r°f '^f- '^''''^ '1^'^-- ^y"'^- te target database systems 

cation data, and non-conventional application data such as 150 & jf ^» 

web page configuration files, • . j 

err- -> • ui 1 J- 11 . . . " ^ computer network 110 may lose. 

« ^n?; t . ? ^^"^ illus ratmg one embotoent^ permute, duplicate or truncate messages. Regardlls, th 

' ^r^^ hTh ^'''Tr Tr T r^"^^"' ^^^^ule 246, 256 must not change the va^of a 

ource database system 140 and the target database system byte that it delivers. It is noted that the mfssaging module 

150 m accordance wi^ the present mvention. As disoissed 246, 256 provides addressing information for l^lng mel 

above, each system 140, 150 is running in its own JVM. sages and lets a message redpient know the identUy o^^the 

Each database system 140, 150 includes a storage module message sender. The messaging module 246, 256 is further 

248fl, 258fl, a system services module 242, 252, a messaging described below, 
module 244, 254, a replication module 246, 256, and a 

database module 248, 258. The messaging module 244, 254, 50 Definitions 

tile replication module 245, 256, and the database module To assist with describing the operation of the present 

248, 258 are coupled to the system services module 242, invention, some terms are generaUy defined. Specifically a 

252. The replication module 246, 256 is coupled to the reference to "AQD properties of a transaction" means that 

^LT^^*^^ database module 248, a particular transaction is atomic, consistent, independent 
258. The respective storage module 248^, 258, is coupled 55 and durable. For example, a transaction is "consistent" if it 

with the respective database module 248, 258. satisfies afi appHcable user defined consistency rules so that 

Tbe storage module 248a, 258a provides information (or the source database also remains consistent. A transaction is 

data) storage within each database system 140, 150. The "^durable" when it will not be revoked by the source database 

storage module 248a, 258a may be, for example, a random system. For example, in the present invention, a transaction 
access memory, a flash memory, a hard-disk drive, a write- <so °iay not be revoked once it is committed by the source 

able CD-ROM, or other functionally equivalent component. database system 140 and, thus, becomes durable. 

The system services module 242, 252 provides low-level A "provisional transaction" is a transaction that was 

system capabilities including creation of a universally applied at a target database but not yet at the source 

unique identifier ("UUID"). The UUID is a conventional database. The provisional transaction may be revoked by 
UUID as described in "DEC/HP Network Computing 65 replication protocol. 

Architecture, Remote Procedure Call Runtime Extensions A copy of the source database is considered "pure" if it 

Specification, Version OSF TX 1.0.11," by Steven Miller reflects only source database system 140 transactions that 
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have been applied in the same order the source database 
applied them. The source database itself is always consid- 
ered to be pure. 

A database "agrees" or is in "agreement" when all copies 
of the source database agree despite minor differences 
between the copies resulting from latency. The copies of the 
source database in a correctly functioning replication system 
must be in agreement, although they may never actually 
match. 

The replication system is considered "correct" if all 
copies of the source database are consistent and agree. The 
source database system 140 enforces all user defined con- 
sistency rules and holds a correct copy of the source data- 
base by definition. A target database is correct if it is 
consistent and agrees with the source database. 

A "conflict** occurs where two transactions are executing 
in different copies of the source database so that the changes 
made by one copy causes changes made by the other copy 
to corrupt the source database. Further, transactions that do 
not modify copies of the same data item can conflict. For 
example, consider transactions that modify the same data 
item and conflict. That is, transaction Tl inserts a person 
with social security number 111-22-3333 at copy CI. Trans- 
action T2 inserts another person with the same social secu- 
rity number at copy C2. The corruption here is that social 
security numbers should be unique. Looking at another 
example, transactions that do not modify the same data can 
conflict. Transaction Tl deletes the sales department firom 
copy CI. Transaction T2 hires a salesman at copy C2. The 
corruption here is that every employee should be in an 
existing department. 

A "commit instant" is a quantity that a database durably 
assigns to a transaction to represent its position in the 
sequence of transactions that the database executed and 
committed. 

A "refresh" operation is performed by the target database 
system 150 against the source database system 140. A 
refresh operation allows the source database system 140 to 
reflect transactions the target database system 150 per- 
formed since a last successful refresh operation. Further, the 
refresh operation allows the target database system 150 to 
reflect transactions the source database system 140 per- 
formed since the last successful refresh operation. 

Refresh Operation 

FIG. 3 is a flow diagram iUustrating the refresh operation 
in the replication processing system 205 in accordance with 
the present invention. When the process starts 310, a user at 
a client computer 130 requests 310 that a target database 
system 150 perform a 'refresh* operation or function. The 
request 310 is made through the replication protocol of the 
target rqilication module 256 which refreshes the cached 
objects that the database module 258 holds. For simplicity, 
assuming that none of the cached data has changed in the 
target database system 150, the target replication module 
256 forms, or generates, 320 a refresh request message. The 
target replication module 256 uses the target messaging 
module 244 to deliver, or send, 325 the refresh request 
message to the source repUcation module 246. 

The source replication module 246 receives 330 the 
message and constructs 335 a refresh reply message. The 
source replication module 246 includes recent changes to the 
data that the target database module 258 has cached in the 
refresh reply message. The source replication module 246 
obtains these changes from the source database module 248. 
The source replication module 246 uses the messaging 
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module 244 to deliver 340 the refresh reply message to the 
target replication module 256. The target replication module 
256 applies 345 the changes in the refresh reply message to 
the target database module 258. This ends 350 the refresh 
cycle. 

Generally, the correctness of the replication protocol of 
the replication modules 246, 256 hinges on a few basic 
principles. First, with respect to the source database system 
140, a new target database initiafly matches the state of the 
source database, and therefore, is also a correct copy. 
Second, a target database executes the same vaUd sequence 
of transactions in the same order. Thus, every copy of the 
source database remains correct. 

As discussed above, the replication protocol operates 
within a hub and spoke topology with the single source 
database 140 and any number of target databases 150. A 
consistent global order of transactions is defined to be the 
order in which the source database system 140 commits the 
transactions. Further, the source database system 140 mns 
all relevant consistency checks whenever it applies a trans- 
action. Thus, the source database system 140 is always 
correct. 

A target database system 150 initially contains a copy of 
the source database system 140 at a given instant. For 
purposes of discussion, the given instant will be refenred to 
as the source copy instant ("SQ**). The target database 
system 150 reflects aU the transactions committed by the 
source database system 140 up to and including the SQ. It 
is noted that because the target database initially matches a 
correct source database state the target database is also 
considered to be correct. 

At any time, the target database system 150 may execute 
the refresh operation to make its copy of the source database 
more current, i.e., match a more recent state of the source 
database. If the target database system 150 has not executed 
any transactions that changed the copied data, it still matches 
the state of the source database at the SCI. The target 
database is considered to be in a "pure" stale and it matches 
the source database at the SCI. During the refresh operation, 
4Q the target database system 150 apphes the same sequence of 
transactions that the source database system 140 applied 
since the last SCI. This transforms the target from a first pure 
state to a second, more recent, pure state. 

Specifically, when the source database system 140 
receives 330 the refresh request message, which includes the 
target database system 150 SCI, it constructs 355 the refresh 
reply inessage. FIG. 4 is a flow diagram illustrating one 
embodiment for constructing the refresh reply message in 
the data processing system 205 accordance with the present 
invention. 

At the start 410 the source database system 140 retrieves 
415 a list of transactions that it has applied since the SCI of 
the target database. The transactions in the list appear in the 
order the source database system 140 committed them. Once 
the source database system 140 retrieves 415 the list of 
transactions, it establishes 420 a new SQ for the target 
database system 150, as is further described below. The 
source database system 140 is now ready 430 to deliver 340 
the refresh reply message 340. 

FIG. 5 is a flow diagram illustrating one embodiment of 
application of the refresh reply message in the replication 
processing system 205 in accordance with the present inven- 
tion. SpecificaUy, at the start 510, the Urget database system 
150 receives 515 the refresh reply message from the source 
database system 140. The target database system 150 effec- 
tively undoes its transactions since the last SCI by returning 
520 the target database to a state of the last SCI. 
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The target database system 150 then applies 525 the list pure state that matches the old SCI of the source database, 

of transactions from the refresh reply message to the target The target database system 150 then applies 675 the source 

database in the same order as the transactions were applied transactions from the list of transactions in the refresh reply 

to the source database. These transactions include the trans- message. These transactions were those performed by the 

actions applied to the target database after the last SCI and S source database system 140 since the old SCI of the source 

that were sent to the source database system 140 in the database. The result 680 is that the target database now 

refresh request message. In addition, the SCI is saved for includes the source transactions. 

Mure reference by the repHcation data processing system when the source database system 140 applies the target 

database 's provisional transactions, the transactions become 

The result 530 is that the target database now matches the lo "durable'' and are assigned a place in the global serial order, 

source database so that the refresh operation transformed the In implementation terms, the source database includes the 

target database from a pure state to a more recent pure state. taiget database's transactions in its ordered list of transac- 

The transfonnation applied to the target database the same tions. 

changes the source database system 140 applied to the -n,e replication protocol of the present invention advan- 

souKe database in the same order as m the hst of transac- « tageousl/provides an understandable transactional consis- 

' tency model. That is, the replication protocol makes it 

The present mvention advantageously performs a trans- beneficiaUy convenient to produce applications because the 

tormation to a target database to create a pure state for that target database is a correct copy of the source database 

target database so that it remains correct. Further, because Moreover, the repUcation protocol makes it easy to verify 

each target database system 150 uses the same refresh 2" that applications running withio the data processing system 

operation, the present invention beneficially allows the 105 are correct because the target database is a oorrea copy 

source database system 140 to define the global serial order of the source database. 

for all transactions in the data processing system 105. «:„,o„» „- j- -.i , , . 

an c ■ n j- ii - . , FIG. 6c is a tmung diagram illustrating one example for 

FIG 6a IS a flo w diagram lUus tratmg one embodiment of application of the transactions described above in FIGS. 6a 

toe refresh operation for transacl_>Dns applied to the target ^ and6<,withrespecttoboth the source database and the target 

database, but not the source database in the rephcation database. It is noted that for this example the initial SQ or 

Tn" m'^''' ^i^i^ "oth the source database system 140 

T.ll^ l ?' transactions are applied to a target and the target database system 150 is SQl. After application 

database, but not the source database, the target database is of the transactions as described above, the new ScJ or new 

fheZ!J;'^',^r P"''^ ^1 Sa2. Further, the target transactiS 

,om, h r*"'' tuT' "^''Tf '° ^ ^^'''^ provisional, are identifi;d as TT and the source 

source database. The transacUons that are appbed to the transactions are identified as ST. 
target database system 150 are, therefore, provisional and 

may later be rejected by the source database system 140. "Consistency" Properties 

At the start 610, the target database has received 615 the jhe present invention includes fiill AQD property guar- 

ZfJ.^al J^' ^''''^r '^''"^ i'" ^ transactions that the sour« dataCy!?em 

TrZTr. provisional tran^cUons until it requests 625 140 commits. In addition, the present invention incTudS 
a refresh operation as described above. TTie refresh request atomic and consistency property guarantees for traSons 

rv?h?'tJ^^;'^rh '!^r""''°"rr^^ ^ '^^^^ '^^^^'^^ syst'if ISO commirSher 

rL l «n ^^^^"^ the Source database system 140 rejects anyZis- 

receives lou me reiresn request message and applies 635 action that would cause It to become mconsistent the. fampt 

'° ^^^^''^^ database system 140. database system 150 transaction remains pmv^nal 

Tie source database system 140 now begins consmiclion the source database system 140 commits if. 

640 of the refresh reply message as described above to ^ ♦ 1, . i=« • , 

generate its result 650 *^ database system. 150 mdudes a limited inde- 

source database system 140 retneves 415 the list of trans- „„*n * i_ r . ^ ^yai^iu ±jv 

* *L 7" ittLn^vca luc u:>L oi irans- will not see changes from any transactions that are uncom- 

smce the ongmal SQ. The list of transactions mcludes the 50 tem 150 may, however, see changes from other provisional 

recently provisional target transactions that the replication transactions. In addition, there is a Umited durabZ^l 

S LfiTv^^/^ .'^"^'t '° ^'^^ 8""=^'^ transactions. That is, transSs r^e 

fhe h!, 7T ^""^^ t""^':""' >° target database system 150 remain provisional untfl the 

SabiL .vTr^dS" °"^V "^'"^^ ^y^^^ 140 commit them Protslona^ 

^u" ''^.^^Tu « transactions that would make the source database inconsis- 

«0 r r '^f f ? ''1 '^r ''i'^'^- ^plication processing system 205 

de£ribed !bove ir^>^ct^or>s as replaces a rejected transaction with a special lylm trans- 

^ _ . ' . action that logs an error in both the source database system 

FIG. 6b IS a flow diagram illustrating a process for 140 and the target database system 150. 

updating the target database system 150 upon receiving the eo 

refresh reply message from the source database system 140 Messaging 

in the replication processing system 205 in accordance with FIG. 7 is a flow diagram iUustrating a more detailed 

the present invention In particular, at the start 660 of this description of the messagng module 244, 254 in the 

process, the target daUbase system 150 receives 665 the cation processing system 205 in accordanci with the pre^nt 

refresh reply message from the source database system 140. ^5 invention. As described above, the target database sys^m 

The target database system 150 undoes any provisional 150 exchanges information with the source database system 

transacUons so that the target database is returned to the last 140 in order to create or refresh its copy of the source 
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database. The information is exchanged by the replication apply transactions to the target database's subset of the 

protocol through messages exchanged between the target source database copy, the source database appears the same 

database system 150 and the source database system 140. to the target database system 150. 

Specifically, at the start 710 the messaging module 254 of source database system 140, the last transaction 

the target database system 150 sends 715 the refresh request 5 committed that changes the copy is outside a particular 

message, including the old SCI, to the source database refresh interval. In other words, one target database system 

system 140. The refresh request message is received 720 by commit instant as the SQ would be indis- 

the messaging module 244 of the source database system tinguishable from another target database system 150 that 

140. The refresh request message includes the list of pro- ^^^^ perform the refresh operation during the particular 
visional transactions that the source database system 140 lO refresh mterval. Thus, the replication protocol does not use 

must apply to the source database. As described above, in transaction to change the published data 

response the source database system 140 constructs an ^ ^^^^^^ database system 140 as the SCI for the target 

appropriate refresh reply message to the refresh request database system 150. Rather, the source database system 140 

message, to send to the target database system 150 manufactures an instant from the time it processes the 

Specifically, the source database system 140 responds ^^^^^h request message, 
through the messaging module 244 sending 725 a refresh ^"""^"^ database system 140 mcludes the SCI it 
reply message to the target database system 150. As ^^^^f^^tures m Uie refresh reply message. The target data- 
described above, the refresh reply message includes the list ^^^^^^ depends on the source database system 140 
of transactions applied to the source database that the target l^.S'"''"^?^ °^ transactions the source database system 
database system 150 must apply to the target database The ^^^^^^ '^^ ^^^^^^ database system 140 
refresh reply message also includes, as also describe above, ^"^^ transactions stored as discussed above, 
the new SQ that the target database system 150 stores ^ discussed above, as the source database system 140 

The refresh reply message is received 730 by the mes- fPP^^^^^^ transactions, the space needed to store this list of 

sagiog module 254 of the target database system 150. As a ^'^^^^^"^^^ grows and the guaranteed refresh interval helps 

result 735 of the interaction between the messaging modules ^ ^'^T^' ^""T^^l^ ' ^^""^ ^'^'^^'^ 

244, 254, the replication module 256 returns the target T T^^u ^^^^^^^ '^^^'^ ^RI, and a 

database to the pure state of the old SCI, performs the souL t^^S^V^atabase system 150 that last performed a refresh 

transactions, performs the stranded transactions, and saves ^j^^^^^ ^ parUcular tmie, e.g., time T, the source 

the new SCI. Tbe stranded transactions are fiirther described ^ff"^"^ T^^"^ 140 guarantees to hold a sufficient number 

below. transactions m its list of transactions to refresh the target 

database system 150 until a time, (T+GRI). 

Data Subsetting It is noted that the limit for the number of transactions in 

The repUcation processing system 205 also supports data °^ transactions is defined in terms of time rather than 
subsetting. In particular, the source database system 140 „ jf^ems of space in order to simplify admi^ 

database copy may contain a large amount of source data hTh T V.T. ^J"'^^'' ^ 

base data, while the copy of the source database (the target f^T ^'""^ ^ f "^'^^ 

database) at the target database system 150 may include only ^^^^""^ consumption of space by the source database system 
a small subset of that data. The replication protocol allows 

the target database system 150 to copy a subset of the source u tJ ^^^^ database system 140 runs out of space by 

database. The target database system 150 may limit what is ?1 ? ^ ^"^^ transactions, the source database system 

copied, for example, one or more columns from a particular \ ^^^^^^ "^"^ transactions and awaits further action by the 

table. °^t^ processing system 105. For example, the data process- 
ing system 105 may have an administrator reduce the 

Data Space Management guaranteed refresh interval or add space to the source 

Tte present invention also manages data space within the ^f^^^^^/ystm 140. The data processmg system 105 may 

data processing system 105. lUe tajet databL syTtrS ± oZ nTaddT' "l^ T ""T '^'''"^ 

depends on the source database sy^em 140 to provide the frl ^^^^^^^ space by discarding old transactions 

fist of transactions that the source database system 140 ^""^ transactions that it no longer needs, 

applied since the last SCI. Over time, as the source database 50 State Names 

system 140 appHes transactions, the space needed within the FIG. 8 is a state diagram iUustrating one example of the 

system to store the list of transactions grows larger. To transaction nature of the source database in a rephcation 

manage the need for data space, the replication processing processing system 205 in accordance with the present inven- 

system 205 includes a process that determines how long a tion. It is noted that the copy of the source database is a 

target database system 150 may safely wait between refresh 55 transactional data set. The copy of the source database 

operations which is referred to as a guaranteed refresh begins in an initial state. Asequence of transactions causes 

mtervaJ ( GRI ), the copy to pass through a sequence of states. For example, 

As discussed above, the target database system 150 stores a transaction, T(i), transforms the copy of the source data- 

the SCI. During the refresh operation the source database base from an mitial state, S(j-1), 810 to a final state Sfl) 

system 140 sends to the target database system 150 trans- 60 820. AS(j-l) is referred to as T(i)'s initial state and SQ) is 

actions after this instant (the SQ). Space management is referred to as T(i)'s final state. Every state S(j) (other than 

also taken into consideration for this mteraction. For the initial state) corresponds to a unique transaction T{i) 

example, consider a source database system 140 that does where T(i) is the transaction that placed the database in state 

not apply a transaction to the source database for more than S(j). Thus, a particular state SQ) has a particular transaction 

the guaranteed refresh interval. The source database may not 65 T(i). 

have any transacdons in the refresh reply message for the The replication system of the present invention benefi- 

target database. If the source database system 140 does not cially exploits the correspondence between each state and its 
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associated transaction to construct a particular name for that system 150. These transactions are provisional and are 

state. For example, the SCI for the transaction T(i) with the stored 920 in storage at the target database system 150. 

final state S(j) serves as the name, e.g., I(T(I)) for a state S(j). When the target database system 150 requests the refresh 

Oqc advantage of constructing the state name in this manner operation, it generates 925 a refresh request message that 
is that given the state name it is easy to determine what 5 includes provisional transactions to date, 

transactions that particular state reflects. For example, given Once the refresh request message is sent to the source 

two stales, SI and S2, executed m a single copy of the source additional provisional transactions continue to be received 

database with two transactions, Tl and T2, respectively, and 930 by the target database system. As noted above, these are 

two names, I(T1) and I(T2), respectively, the definition of an stranded transactions because the target database system 150 
instant imphes that the following relationships hold: lo is performing them after it akeady sent the refresh request 

if I(T1)<I(T2), state SI occurred before state S2; message. The target database system 150 stores these 

if I(T1)=I(T2), state SI is state 82; and stranded transaction in storage. 

if I(T1)>I(T2), state SI occurred after state S2. As discussed above, at the source database system 140, 
Given the target database state name, the source database the refresh request message is received 935 and the provi- 
system 140 can determine the list of transactions needed for sionaJ transactions are applied 940 to the source database, 
the target database system 150. For example, if the state The source database system 140 constructs 945 and trans- 
name for the target database is the SCI, the target database mits the refresh reply message to the target database system 
needs transactions that affect the target database and conamit 150. The target database system 150 receives 950 the refresh 
after the SQ. Further, recovery processes, such as those reply message and returns 955 the target database to the last 
described below, rely upon the ability of the target database pure state. The target database system 150 applies 960 the 
system 150 to return the target database to a state that is source transactions from the refresh reply message to the 
earlier than a state of the source database. Specifically, the target database. 

target database system 150 returns the target database to a After applying 960 the source transactions, the target 

state with a name that is less than or equal to the source database system 150 appHes 965 the stranded traiisactions in 

database state name. 25 ^^^^^^^ ^^^^^ database. Tlie target database system 

Slow Messaeine ^^^^^ ^^^^^ ^® 

^ ^ based on transactions applied from the refresh reply message 

In one embodiment of the present invention, the replica- before the stranded transactions are applied. The result 980 

tion protocol allows for communication between the source of the process is successful application of stranded transac- 

database system 140 and the target database system 150 tions to the target database. These transactions are now ready 

using slow messaging, for example, electronic mail. The to be applied to the source database in the next refresh 

time interval between when the target database system 150 operation, 
sends the refresh request message and when it receives the 

refresh request reply from the source database system 140 Disaster Recovery 

may be long. To enhance database availabihty, the repHca- The repHcation protocol of the present invention also 

hon protocol allows applications to update the target data- allows for fast, ef&cient disaster recovery, for example when 

base system 150 during this interval. the source database recovers from a backup and loses some 

When the target database system 150 receives the refresh recent transactions. The replication protocol automatically 

reply message, the list of provisional transactions may 4q restores agreement for the target databases of each target 

include some transactions that have been sent to the source database system 150 without requiring separate database 

database system 140 in the refresh request message, as well administration. 

as other transactions that have not been sent because these In one embodiment, the replication protocol is extended 
transactions were committed after the refresh request mes- with two extensions. The first extension includes "detection" 
sage was sent. After.the target database system 150 applies 45 and allows the target database system 150 to detect that the 
the hst of transactions from the source database system 140, source database system 140 has recovered after being dis- 
mcludmg the provisional transactions received from the abled and has possibly lost some transactions The second 
target database system 150, the target database system 150 extension includes "correction" and allows the target data- 
must re-apply any provisional transactions that were com- base system 150 to return lo a vaHd pure state. Because the 
mitted after traosmittmg the refresh request message. 50 valid pure state includes no transactions that the source 
Further, the target database system 150 must remember that database system 140 lost, the target database system 150 
the re-appHed transactions are still provisional. may resume normal operation. The two extensions are 

Thus, there may be a long time lapse between when the described in further detail below, 

target database system 150 constructs the refresh request Turning first to the detection process, generaUy each 

message and when the source database system 140 processes ss database includes a generation name. The generation name 

an appropnate refresh request reply. During this time, trans- is a unique identifier for that database. Restoring the data- 

actions may contmue to be processed at the client computer base from a backup of the database changes the generation 

target database system. These transactions, however, are name. Thus, the generation name provides identification as 

provisional and are referred to as "stranded" transactions to when a particular database has been restored from its 

during this period. Nonetheless, these stranded transactions 60 backup. 

are yet to be processed by the replication processing system The replication protocol keeps correct by beneficially not 

CTr- ft • « ^. .„ . allowing generation names to repeat. If the generation name 

J'/ ^ diagram illustratmg processing of the is repeated, it could not be used to determine if the database 

stranded transactions m conjunction with a refresh operation had been restored from its backup. Because generation 

in the rephcation processing system 205 in accordance with 65 names do not repeat, it is incorrect to construct the genera- 

the present mvenUon. To start 910, as described above, tion name from a couQter stored in the database. The counter 

transacUons are typically received 915 at the target database itself gets reset when a database is restored from the backup 
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In one embodiment, the replication protocol uses the UUID and the source database system 140 by performing a refresh 

(described above) for a generation name. operation, as described above. It is noted that the target 

FIG. 10 is a flow diagram illustrating the detection database system 150 rejects provisional transactions that 

process with respect to failures within the replication pro- violate database consistency rules and logs errors as needed 

cessing system 205 in accordance with the present iaven- 5 through this process. 

tion. At the start 1010 it is noted that the detection process • Looking further at the recent stable ptire state, the recov- 

is extended to the refresh operation as described above. *^ procedure is dependent upon the target database system 

Initially, the target database system 150 stores the generation returning to the stable pure state during the disaster 

name of the source database when the target database is recovery process. There is, however some complexity, 
created. The target database system 150 then includes 1020 lo During normal operation, the target database system 150 

the generation name of the source database in the refresh '° identify the source database state, 

request message sent to the source database system 140 Unfortunately, after the source database system 140 recovers 

When the source database system 140 receives the refresh ^Tn^^^.^t^ °''""''?" T"' 

request message, the source database system 140 verifies ^ZT^^lTlT'f 

1025 the generation name received from the target database ""^t^"' '^^V f ^^^^ «t°red on the 

system 150 with the current source database system 140 ^^f^P- '^^^ P'«iuced by the counter after the 

generation name. If the source database sysL S de^eV- ^^Z.ZIZT^' r""^"' " '°T^ ^""^^ ' 

minesl030thatthegenerationnamesmatch,theresultl040 ° ""'^^^^TT'^^. f « — 

is that the source database system 140 processes the refresh ^L^^^IS, ,f ^^f I'"' 

request message normally as is described above "^^J ^'''^ '=°'"m< "i^tant for a lost transaction. 

If the source database system 140 determines 1030 that J" tirrf 'at an Z^Z 1m^''k'''"^ t^^'? ' 

the generation names do not match, the source database «S Itl ^^ J^ ^^TP 

system 140 sends 1035 the target dLtabase system 150 a ^Zl^u'^! t:^^^^T T "°TT ''''''' 

recovery message. Ihe recovery message informs the target S f^ltZ,T T * ''^""^ "P*'"""""' 

database system 150 that corrective action must be takfn. '^^'T^ ""^"^ 

Ite result 1040 is that the recovery message contains the aS;^^^ T'' '^'''^r u^''''^ 

new source database system 140 generation name Jl'" ^ "^^^^^l ^^^""^^ *e s°«ce database system 

„ , ,u .. r^,T7^ . ^ 1^ ^irce database from a backup. The transaction Tl is 

IMmmg next to the correction process, FIG. 11 is a flow lost and the state I(T1) is no longer a valid source database 

^fr^,,fw ^ ^^."'T,'r r^"™"'' 30 s'ate. Later, the source databa^ system 140 executes a 

target database sj^tetn 150 receives the recover message transaction Tl' at instant, I(T10. Its commit instant 

^^LSn/rr ''f however.matchesthecommiti^sJtforthelos^LsacS 

processing system 205 in accordance with the present inven- Tl so that TmUTm Tf th^ ur-rr^i ^.i.u.^^ a^^a^uyji± 

tion. Once the process is started 1110, the re'plication pro- f.^r^^'^^^l^lr^^ 'X^^^ 

5roT;?cTnSrreita1e^^^ - T'T'' ''^^^^^^ ^'^''^(") namTas t stS 

15« to a recent stable pure state. Moreover, the state I(T1) falsely appears to be pure 

Ihe recent stable pure state is a pure state that docs not and stable 

H.^h.T , 1.1^^ a presumption that the source 150 to return to the stable pure state after the source database 
t^lZ ^ 140 recovered from a backup and the target ^ system 140 recovers from a backup by having the replication 

aT y Processingsystem205performparti^arprocedur^dur^ng 

JvS 1^" ? ^""^ ''''^"^'^ d^'^base sj^tem 140 durabty 

fnfl?H iti ATfr^V°lu it Pe^- stores one or more stable names that correspond to a smaU 

formed (but did not lose) after the pure state of the target number of distinguished states. The naies are stable 

tt^ZJ'Tl i ; ""'^^ '^"^ '^^ « "^'"^ ^'^^^^ ^^^'^ 140 does not 4e them 

ttLTn r T""" ^v''"^^'" ™- ''^^^ 'hovering from a 

tency and restoresagreement withm the replicaUon process- backup. In one embodiment the source database syl;m 140 

^^system 205. The recent pure state is fiirther described uses UUIDs to serve as stable names. 

, „ To associate the particular stable name with the particular 

Next, the target database system 150 extends 1120 the list so state, the source database system 140 executes a marker 

of provisional transactions to include all target database transaction that contains the stable name. The marker trans- 

transacuons that the recovered source database may have action may be executed by the source database system 140 

lost There IS a presumption that when the source database at any time. In one embodiment, the source database system 

system 140 recovered the source database it went back in 140 executes the marker transaction as part of an operation 

Ume. The source database system 140 may have lost some ss that creates a backup copy of the source database, as is 

of the transactions m the target database system 150. The fiirther described below 

target datab=^ system 150, however, recovers these last FIG. 12 is a flow diagram illustrating the marker trans- 

sv^mT^ T;,e"in! '° ^ replication'processing syftem 275^ ac^- 

system 140. The potentially lost transacUons mclude any dance with the present invention. Once the process starts 

aftTt^fsTabStie'statr '° ^O. the source database system 140 creates 1215 a ma*« 
atter the stable pure state. for a stable pure state. Ihe source database system 140 stores 
Ihe target database system 150 also stores 1125 the new 1220 the newly created marker. The source database system 
source database system 140 generaUon name that it received 140 commits 1225 a transaction as described above When 
m the recovermessage from the source database system 140. the transaction commits, the source database system 140 
The target database ^stem 150 then starts from the stable 65 saves 1230 the marker and the commit instant for the 
pure state to redo 1130 the provisional transactions and transaction with the list of transactions of the source data- 
make their effect visible at the target database system 150 base system 140 that change the data 
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The marker and the commit instant are included in the 
refresh reply message back to the target database system 
150. The result 1235 is that the marker transaction corre- 
sponds with the source database state at the instant the 
marker transactioD commils so that the target database 
system 150 can determined the stable pure state. Further, this 
instant is referred to as the marker state. 

Similar to other transactions, the source database system 
140 adds the marker transaction to its list of recent trans- 
actions. The backup of the source database system 140 
contains the recent list of transactions, including marker 
transactions. As a result, the source database system 140 
stores the stable names for the recent marker transactions for 
when it recovers from the backup. After the source database 
system 140 completes recovery of the source database, there 
are sufiScient transactions in the source transaction list to 
process the refresh request message from the target database 
system 150 that is in any marker state that the source 
database system 140 stores. 

Thus, the marker state is a pure source database state 
because it contains no lost transactions. In addition, the 
marker state has a stable name, and hence, is a pure stable 
state. TTiis allows a target database system 150 to correctly 
perform the refresh operation. Specifically, by returning the 
target database to a stable pure state, which is the state the 
source database was in after a marker transaction, the target 
database is in agreement and can correctly perform the 
repHcation protocol. 

During operation of the present invention, the target 
database system 150 also prepares for a possible failure of 
source database system 140. Specifically, when the target 
database system 150 applies the marker transaction it 
remembers or stores both the stable name as well as its own 
state. Thus, during normal operation, the target database 
system 150 keeps a small list of recent stable pure states and 
their stable names. 

In summary, to prepare for a possible source database 
system 140 failure, source database system 140 and target 
database system 150 store extra information. Specifically, 
the source database system 140 stores the marker transac- 
tions in its list of transactions. The marker transaction 
includes the stable name. The target database system 150 
stores a small number of the stable names. For each stable 
name, the target database system 150 also stores the asso- 
ciated pure state. . 

The source database system 140 includes the list of stable 
names for all the marker transactions that the source data- 
base system 140 stores in the database recovery message. 
From the list of stable names, the target database system 150 
selects the most recent stable state whose name the target 
database system 150 remembers. The target database system 
150 returns to this most recent stable state in the first step of 
the corrective action procedure described above. 

If the target database system 150 does not remember a 
state whose name the source database system 140 included 
in the recover message (i.e., there is no overlap between the 
sets of stable states the two databases store), the target 
database system 150 cannot perform the refresh operation. 
Thus, the target database system 150 must make a new copy 
of the source database. The target database system 150, 
however, may still submit its provisional transactions to the 
source database system 140 using a separate mechanism 
referred to as a submit process. 
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cannot perform a refresh operation. FIG. 13 is a flow 
diagram illustrating a submit transactions operation in the 
replication processing system 205 accordance with the 
present invention. At the start 1310, the target database 
system 150 receives 1315 provisional transactions similar to 
that described above. Also as described above, the target 
database system 150 stores 1320 these provisional transac- 
tions in storage. 

The target database system 150 requests 1325 a submit 
operation to the source database system 140, The source 
database system 140 receives 1330 the submit operation 
request and appHes 1335 the provisional transactions to the 
source database. Once the provisional transactions are 
applied, the source database system sends 1340 and the 
target database system 150 receives 1345 a reply indicating 
that the operation is done. The result 1350 is that the 
provisional transactions at the target database system 150 
are applied to the source database despite not performing a 
refresh operation. 

Once a source database system 140 database is recovered 
from a backup, it is possible that it may lose a transaction 
from the target database system 150. If the target database 
system 150 stores and resubmits the transaction it will not be 
lost from within the replication processing system 205. It is 
noted that if all transactions come from the target database 
systems 150, no transactions are lost when rebtiilding a 
source database system 140, 

The replication protocol of the present invention allows 
for resubmission of transactions from the target database 
system 150 that may be lost by the source database system 
140. Specifically, for each target database system 150 the 
source database system 140 stores the particular target 
database system 150 identification or name and a target 
instant ("TI'*) for the target database system 150, It is noted 
that the TI identifies a given instant in time with respect to 
the state of the target database. 

The stored name may be a UUID as described above. The 
stored Tl indicates the last transaction that occurred in the 
target database system 150 that is committed by the source 
database system 140. The recovery message from the source 
database system 140 includes the TI for the last committed 
transaction by a particular target database. The target data- 
base system 150 extends its list of pending transactions to 
include all target database system 150 transactions after the 
TI. 

The replication protocol in accordance with the present 
invention aUows for effective space management dtiring the 
recovery process in the data processing system 105. 
Generally, a "well-behaved" target database system 150 
completes a refresh operation at least as often as the guar- 
anteed refresh interval. The target database system 150 also 
stores stable pure states within the guaranteed refresh inter- 
val of the target database's most recent refresh operation. 

When performing corrective action, for example, disaster 
recovery, the target database system 150 stores the stable 
pure state that the source database system 140 included in 
the backup. The target database system 150 only stores 
stable pure states within the guaranteed refresh interval of 
the most recent refresh. Thus, the source database system 
140 must define the stable pure state once every guaranteed 
refresh interval to assure that the target database system 150 
will always store the most recent stable pure state. To define 
the stable pure state the source database system 140 executes 
the marker transaction and makes the backup as described 



The submit process allows the target database system 150 65 above, 
to submit its provisional transactions to the source database To understand the time interval for the source database 
system 140 even though the target database system ISO system 140 to aUow the target database system 150 to 
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perform the refresh operation from the stable pure state, sentation of data is standard at all nodes in a network, the 

consider an extreme case in which the target database system checksum functioQ does not cope with different and incom- 

150 infrequently performs the refresh operation and the patible representations for the same item of data in different 

source database system 140 infrequently defines the stable databases. Thus, the correctness of this process does not 

pure stale. In this example, a present time may be referred 5 depend on the unit of information imdergoing the checksum 

to as TN, the guaranteed refresh interval may be referred to calculation. A particular implementation may check, for 

as GRI, and the time of the last refresh operation may be example, whole tables or only row subsets of large tables 

referred to as RT It may be assumed that the target database Checksums also may be used to verify meta-data as well 

system 150 ^ well behaved. Ibus, the last refresh operatioa ^s user data. For exaiiple, the verification fonction may 

was within the guaranteed refresh interval, so that RT>TN- lo indicate that the target database system 150 is not in agree- 

RSPST ^"^^ ""'^ ''^^''^^ '^P^"^' ^oncdivc action is to throw away the 

" copy of the source database and create a new copy. This may 

nie recent stable pure state, RSPST, that the target not be desirable if the copy contains a large volume of data 

database system 150 stores must be within the guaranteed and only a small portion is incorrect. Thus, the replication 

refresh interval of the most recent refresh operation by the 15 protocol performs a correction process on the target database 

target database system 150. Specifically, RSPST>RT-GRI system 150. 

^'^i""' '"f ' The correction p«>cess includes the taigel database sys- 
database systein 150 returns to the recent pure state so that 150 having the name of the incorrect item in the refre^ 

stZ'^So'^ ''T""". ,n -<1-^' --^i- -^-"Pl'. - 'able iSciLn ort 

^stem 150. The recent pure stables ate ,s not earher than 20 .able identification with and a predicate such as orders 

^T. ,t srr^f h . T^n '""r'l- '^^^'^^ 1=0° l^^. ^e so^e database system 140 

^T;,^^ r 7,n'?!*. °' "^"^ '"""^'^ « «=-<=°Py transaction that selects the correct data 
lut 1h ^^T H f '^^'^<='»°°« Finally, the target database system 150 applies the re-»py 

hst for twice the guaranteed refresh mterval. It is noted that transaction by applying the a,rrect version of the itemZ^ 

.trri r r it l^-r^only store transactions 25 databaL^ten. 140 selected 

since the last marker that is older than the guaranteed refresh r^rc ia a a .„ 

interval. '^'"^' 1'** diagrams illustratmg one 

embodiment of a checksum process for the repKcation 

Agreement Verification processing system 205 in accordance with the present inven- 

. J. J u . , 30 tioi- FIG- 14a illustrates the checksum process in which the 

As discussed above, the rephcaUon protocol of the present source database system 140 computes a checksum usine a 

invention supports agreement verification in the target data- checksum transaction, with every transaaion data 'set. :nie 

base system 150. TTie target database system 150 inchides an checksum is calculated so that it can be provkJed to the tarcet 

mstruction mdicahng that it wants to verify itself in the database system 150 

^:^:7:rlZ^li:^^,T.7oaT^ - ,^^;-—f-lJ02 Wiethe source da^ 

refresh request message. lUe verification transaction com! IZTtP ^ 1""' ^^'^ 

putes and records one or more checksums for the dataTat itSefreak'^S- 'the cS" 

the target database system 150 holds. The verification trans- TclZ^d ta «t i«u^t' -A. k ' 

action perfonns proper locking to ensure that it computes liof L 1^.^ t v 

checksums for consistent data sets. T t 1 i "^^^^"^ "? ^ checksum transaction in 

^ , . refresh reply message. The mcluded checksum transac- 

It IS noted that a checksum is a number computed by tion holds the checksums that the source database system 

app ying a function to some data. Every time the fimction is 140 computed. The result 1408 is that source database 

applied to the same data, the result should be the same. system 140 transmits the checksums with the refresh reply 

Suni arly if the fiincUon is applied to different data, the 45 message for the target database system 150 

result should usually be different. Thus, in the present err. la^ .u- u 1 

invenUon, the source database system 140 and the targe d»t^h?« r?^n .f"? ^l""""^ 

d»taha« «v«(Pm 1 <ft „r.c.„„.-i ^Z.^A,u j . j database system 150 receives the checksum transaction. The 

aaiaoase system 150 are presumed to hold the same data and nmcew starts liin witt, th» A.t.u . 

L%tfnSu"ird£?th'°''*^^^^^^ ^^^^T^^^^^^SiZ'L1.7arl^y 

r^rXrn l^^^hirri rf f ! ' 50 message. Then for every data set with a checksum in Sie 
a problem withm the rephcation processmg system 205. By checksum ti^action, the target database system ISO a^ 
UMng checksums, the present mvenUon allows for compar- computes 1415 a checWum. lie target d^a^aiTystem S 
mg copies of the target database with the source database compares 1420 the computed checksum to &e checks^ 
TetoA iTr " '''' — database system 140 frthat dalatltr 
■ ss target database system 150 determines 1425 that the check- 
When the target database system 150 apphes the verifi- sums mateh, the target database system 150 concludes that 
cation transaction the state of the target database should the data sets are in agreement. The result 1440 is that a data 
mateh the state of the source database at the time the source set is valid 

h T"*'' transaction. if the target database system 150 determines 1425 that the 

^^S^^^r^Tr "° P^"^,^^"""^ tra^cuons at checksums do not match, then the target database "m 

ptv^^a^tiSora^rc"^^^^ i^aixrTh''" ? r t ^ ^s--' ^-^ 

copied data. If the copy ^ correct, the checksu^st t Sbat systim llll^t. 1^0 f new^p^; of 

irrb^^SmSXutS.^'^'^^''''''^^ , setwithChlm.^^^^^^^ 

- . .. , ^ J " system 140. The source database system 140 executes 

In one embodiment, the rephcaUon protocol is imple- 1435 a special copy transaction in the list of transactions that 

mented through Java data formats. Because the Java repre- are sent in the refresh reply message to the target database 
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system 150. The target database system 150 receives 1440 result 1550 is that the application is upgraded quickly and 
the refresh reply message and applies 1445 the transactions efficiently without time consuming operator or user inter- 
in the list of transactions, including replacing the invalid vention. 

data set. Thus, the target database system 150 may be FIG. 16 is a flow diagram illustrating a process for the 
repaired without having to re -copy all its data, thereby s source database system 140 to build an upgrade reply 

saving processing resources and time. message in accordance with the present invention. Once the 

process starts 1610, the source database system 140 con- 
Upgrade Process structs 1615 an empty upgrade reply message. The source 
The replication protocol in accordance with the present database system 140 determines 1620 what are the applica- 
invention also allows for proper software upgrade process, m the apphcatioQ version list 
The refresh request message includes a target database ^ SpecificaUy, Oie source database system 140 reads 1625 
software version identifier. When the source database sys- ^LTl^inTth T T ""^f^^^^^^ f ^ deter- 
tem 140 processes the refresh request message it first checks T^Z f^^w'^l apphcation version at the target database 
#K^*n™fj.*«K ft • L J -J .-^ system 150 IS older than the apphcation version at the source 
inhpTl. H ^^7^.7^^,^°^^ ^^^d this identifler. database system 140. If the application version at the tar^Tt 
f the target database idenufier shows a version that is older ^5 ^^^^^^^ ^^^^^^ ^ ^^^J^^ ^^^^^ ^ 

than the source database software version, the source data- database system 140, an upgrade block is added 1635 to the 

base system 140 responds with an upgrade reply. upgrade reply message for that apphcation. Tlie upgrade 

The upgrade reply includes a upgrade utility enabled by a block includes application information, including applica- 

Java class that implements the upgrade logic, the target tion identification new version, old version, an apphcation 
database software version identifier after the upgrade, and ^° specific upgrade utility and application specific information, 

the information needed by the upgrade utihty to upgrade the If the application version at the target database system 150 

target appUcation. This information may include more is not older than the application version at the source 

classes used by the upgrade utiUty, the new system software, database system 140, then the source database system 140 

and new error messages. It is noted that the upgrade message determines 1620 if there are any more appHcations in the 
may be customized to include information specific for any ^ apphcation version list. Once all the applications are read 

application. This mfonnation includes any information that from the application version list and all the upgrade blocks 

a chent computer or a target database system needs to are added 1635, the process is completed 

properly upgrade the application. The result 1640 is that the source database system effi- 

Also with respect to the information needed by the cienUy determines what applications at the target database 

upgrade utiUty, the upgrade utility defines the form and system 150 need upgrading and sends the appropriate 

content of the mfonnation it needs. Having the upgrade upgrade information in the upgrade reply message It is 

utility define the form and content of the information it needs noted that if an apphcation is not required to be upgraded 

avoids definmg a rigid repHcation protocol now to meet all the repHcation data processing system 205 processes the 

future upgrade requirements. Thus, applicaUon developers refresh operation as described above 

^""^r'^-^'n "^t^ r """^ ^^^^y P^^- 1^ ^ ^ fi^^ ^^g^^ illustrating a process for the 

^Uiout being hmited by the replication processmg system target database system 150 to receive and apply the upgrade 

_ reply message in accordance with the present invention. 
To perform the upgrade process, the target database Specifically, the process is described with respect to each 
system 150 processes the upgrade message. Specifically, the upgrade block in the upgrade reply message 
target database system 150 reads the upgrade utiHty class At the start 1710 of the process, the target database system 
from the upgrade message. The target database system 150 150 receives the upgrade i^ply message and reads 1715 the 
loads the upgrade uUlity into the target JVM and execute the apphcation identification information for the upgrade block 
classes upgrade method. The upgrade utihty is then executed Next, the target database system 150 reads 1720 the new 
by the target JVM. The target database system 150 then 45 apphcation version and reads 1725 the old apphcation 
provides the message as input. version. Tbe target database system 150 determines 1730 if 
FIG. 15 is a flow diagram illustrating an upgrade process the old application version matches the old apphcation 
and utility for the replication processmg system 205 in version it holds. If the old application versions do not match, 
accordance with the present invention. At the start 1510 of the result 1750 is that the process ends, 
the process, the target database system 150 includes 1515 an 50 If the target database system 150 determines 1730 that the 
application (or software) identification and an application old apphcation veisions do match, it reads 1735 the byte- 
version to an application version Hst in the refresh request code for the upgrade utility from the upgrade block and 
message. The source database system 140 receives 1520 the loads the utility into the target JVM. The target database 
refresh request message and inspects 1525 the appUcation system 150 then gets 1740 tiie Java input stream for reading 
version list. 5^ the remaining bytes from the upgrade block. This is pro- 
Based on the inspection, if Uie source database system 140 vided by the target database system 150 messaging module 
determines 1530 that the apphcation version is not older 254. It is noted that the content and the meaning of the bytes 
than the apphcation version of that application at the source ^ the Java input stream are defined through Uie upgrade 
database system 140, then the result 1550 is no upgrade utility. 

reply is necessary. If tiie source database system 140 deter- 60 The target database system ISO then invokes 1745 the 

mines 1530 that the application version is older than the upgrade utiUty to pass the application information, including 

application version of that application at the source database the application identification, the new version old version 

system 140, then it builds 1535 an upgrade reply message as and Java input stream information. The result'l750 is that 

described below. The source database system 140 sends, or the target database system upgrades its application quickly 

transmits, the upgrade reply message to the target database 65 and efficientiy without operator or user intervention 

system 150 which receives 1540 it and accordingly performs It is noted that an application depends on many indepen- 

1545 an upgrade of tiie apphcation as described below. The dentiy developed software components. These include data- 
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base software, application software and system software 
such as the Java Development Kit. In addition version 
dependencies between components are common. For 
example, version A.X of an application uses a feature 
introduced in version DB.Y of a database management 
database. Version A.Y of an application may not work with 
version DB.Z of a database management system due to a 
regression or use of a deprecated feature. 

Thus, an upgrade must account for all the software an 
application uses. The replication protocol allows users to 
upgrade any software component, as well as user data, using 
a process similar to that described above. Specifically, to 
upgrade a software component, a user must register the 
particular information in advance. 

Registration is accomplished by writing components for 
an application that can be registered with the source data- 
base system 140. Specifically, these components include a 
Java class that implements ^'upgradable*' and a Java class to 
add upgrade information for the application to the upgrade 
reply message. The replication processing system 205 then 
allows the application and upgrade information to be regis- 
tered with the source database system 140. Registration 
includes providing the application identification, for 
example, the UUID, the application version, for example, a 
program string, and the application upgrade utility. One 
skilled in the art will recognize that new versions of an 
application maybe registered in the same manner. Finally, an 
application will be included in a target database copy and 
includes the application identification and version informa- 
tion. 

While particular embodiments and applications of the 
present invention have been illustrated and described, it is to 
be imderstood that the invention is not limited to the precise 
construction and components disclosed herein and that vari- 
ous modifications, changes and variations which will be 
apparent to those skilled in the art may be made in the 
arrangement, operation and details of the method and appa- 
ratus of the present invention disclosed herein without 
departing from the spirit and scope of the invention as 
defined in the appended claims. 

What is claimed is: 

1. A method for updating a source database and a plurality 
of target databases so that at a given instant the source 
database and the plurality of target databases are in 
agreemeDt, the method comprising: 

respectively establishing a plurality of pure states between 
the source database and the plurality of target data- 
bases; 

asynchronously receiving at the source database a respec- 
tive plurality of refresh requests from the plurality of 50 
target databases, wherein each refresh request is from a 
requesting target database and includes any provisional 
transactions applied to the requesting target database 
since the requesting target database's last pure state; 
and 55 

asynchronously responding to the plurality of refresh 
requests from the respective plurality of target data- 
bases by: 

applying any provisional transactions from the request- 
ing target database to the source database; 

providing the requesting target database with the trans- 
actions applied to the source database since the last 
pure state of the requesting target database including 
any provisional transactions applied to the request- 
ing target database; 

restoring the requesting target database to its last pure 
state; and 



15 



20 



25 



30 



35 



45 



60 



65 



applying to the requesting target database the transac- 
tions applied to the source database since the last 
pure state of the requesting target database. 

2. The method of claim 1, further comprising establishing 
a more recent pure state for each requesting target database 
in response to applying the source transactions from the 
source database to the requesting target database. 

3. The method of claim 1, further comprising: 

collecting a stranded transaction at a requesting target 
database; and 

applying the stranded transactions to the requesting target 
database after applying the transactions from the source 
database to the requesting target database. 

4. The method of claim 1, further comprising: 
performing a checksum transaction with each transaction 

applied to the source database to generate a source 
checksum; and 
providing the source checksimi to each requesting target 
database upon responding to the target database's 
refresh request. 

5. The method of claim 4, further comprising: 
performing a checksum transaction with each source 

transaction applied to the requesting target database to 
generate a target checksum; 

comparing the target checksum with the source check- 
sum; and 

re-providing a source transaction from the source data- 
base to the requesting target database in response to the 
target checksum and the source checksum being mis- 
matched. 

6. A method for restoring agreement between a source 
database and a target database in the event of a failure, the 
method comprising: 

receiving a refresh request from the target database, the 
refresh request containing a target generation name 
identifying a stable pure state of the source and target 
databases; 

verifying agreement between the target generation name 
and a source generation name stored at the source 
database; and 

recovering the source database in response to a mismatch 
between the source generation name and the target 
generation name. 

7. The method of claim 6, wherein the step of recovering 
the source database comprises: 

receiving the source generation name at the target data- 
base; 

extending the list of provisional transactions stored by the 
target database to include all transactions stared by the 
target database since the stable pure state identified by 
the source generation name; and 

performing a refresh operation to commit the extended list 
of provisional transactions stored at the target database 
on the source database in order to recover the source 
database. 

8. The method of claim 7, further comprising: 
periodically performing a marker transaction at the source 

database, the marker transaction identifying a pure state 
of the source and target databases by a source genera- 
tion name; 

storing the source generation name at the source database 
and supplying the source generation name to the target 
database in response to a refresh request firom the target 
database. 
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9. The method of claim 8, wherein the stable pure state is 
identified by a UUID. 

10. In a replication processing system having a source 
system and a target system, a method for upgrading an 
application in the target system comprising: 

providing an application identifier and a source applica- 
tion version for the application at the source system; 

receiving a target application version from the target 
system; 

building an upgrade packet in response to the target 
appHcation version being older than the source apph- 
cation version; 
providing the upgrade packet to the target system; and 
performing an upgrade of the application at the target 
system in response to receiving the upgrade packet. 

11. The method of claim 10, wherein the upgrade packet 
further comprises the application identifier, the source appli- 
cation version, the target application version, an application 
upgrade utility and data bytes for upgrading the application. 

12. The method of claim 11, wherein the step of perform- 
ing the upgrade at the target system further comprises: 

reading the application identifier from the upgrade packet; 
reading the source application version and the target 

application version from the upgrade packet; and 
reading the bytes from the upgrade packet for upgrading 

the application in response to the target application 

version from the upgrade packet matching the target 

application version at the target system. 

13. A computer program product, implemented on a 
madiine readable medium, comprising instmctions operable 
to cause a programmable processor to: 

respectively establish a plurality of pure states between a 
source database and a plurality of target databases; 

asynchronously receive at the source database a respec- 
tive plurality of refresh requests from the plurality of 
target databases, wherein each refresh request is from a 
requesting target database and includes any provisional 
transactions applied to the requesting target database 
since the requesting target database's last pure state; 
and 

asynchronously respond to the plurality of refresh 
requests from the respective plurality of target data- 
bases by: 

applying any provisional transactions from the request- 
ing target database to the source database; 

providing the requesting target database with the trans- 
actions applied to the source database since the last 
pure state of the requesting target database including 
any provisional transactions applied to the request- 
ing target database; 

restoring the requesting target database to its last pure 
state; and 

applying to the requesting target database the transac- 
tions applied to the source database since the last 
pure state of the requesting target database. 

14. The computer program product of claim 13, further 
comprising instructions operable to cause the programmable 
processor to: 

collect a stranded transaction at a requesting target data- eo 
base; and 

apply the stranded transaction to the requesting target 
database after applying the transactions from the source 
database to the requesting target database. 

15. The computer program product of claim 13, further 65 
comprising instructions operable to cause the programmable 
processor to: 
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periodically perform a marker transaction at the source 
database, the marker transaction identifying a pure state 
of the source and target databases by a source genera- 
tion name; and 

store the source generation name at the source database 
and supply the source generation name to the target 
database in response to a refresh request from the target 
database. 

16. The computer program product of claim 13, further 
comprising instructions operable to cause a programmable 
processor to: 

compute a source checksum at the source database for 

each source transaction; and 
provide each source transaction and the source checksum 

for each source transaction to the target database upon 

responding to the requesting target database's refresh 

request. 

17. The computer program product of claim 16, further 
comprising instructions operable to cause a programmable 
processor to: 

perform a checksum transaction with each source trans- 
action applied to the requesting target database to 
generate a target checksum; 

compare the target checksum with the source checksum; 
and 

re-provide a source transaction from the source database 
to the requesting target database in response to the 
target checksum and the source checksum being mis- 
matched. 

18. The computer program product of claim 15, further 
comprising instructions operable to cause the programmable 
processor to: 

receive a refresh request from the target database con- 
taining a target generation name identifying a stable 
pure state of the source and target databases; 

verify agreement between the target generation name and 
a source generation name stored at the source database; 
and 

recover the source database in response to a mismatch 
between the source generation name and the target 
generation name. 

19. The computer program product of claim 18, further 
comprising instructions operable to cause the programmable 
processor to: 

receive the source generation name at the target database; 

extend the list of provisional transactions stored by the 
target database to include all transactions stored by the 
target database since the stable pure state identified by 
the source generation name; and 

perform a refresh operation to commit the extended list of 
provisional transactions stored at the target database on 
the source database in order to recover the source 
database. 

20. A computer program product, implemented on a 
machine readable medium, containing instructions operable 
to cause a programmable processor to: 

provide an application identifier and a source application 
version for an application at a source system; 

receive a target application version from a target system; 

build an upgrade packet in response to the target appli- 
cation version being older than the source application 
version; 

provide the upgrade packet to the target system; and 
perform an upgrade of the application at the target system 
in response to receiving the upgrade packet. 
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21, The computer program product of claim 20, whereio 
the upgrade packet further comprises the application 
identifier, the source application version, the target applica- 
tion version, an application upgrade utility and data bytes for 
upgrading the application. 

22. The computer program product of claim 21, wherein 
the instructions to perform an upgrade at the target system 
further comprises instructions to: 

read the application identifier from the upgrade packet; 
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read the source application version and the target appli- 
cation version from the upgrade packet; and 

read the bytes from the upgrade packet for upgrading the 
application in response to the target application version 
from the upgrade packet matching the target applica- 
tion version at the target system. 
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